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1. INTRODUCTION 
1.1 The Internet Domain Name System 


The Domain Name System (DNS) provides for the translation between 
hostnames and addresses. Within the Internet, this means translating 
from a name such as "venera.isi.edu", to an IP address such as 
"128.9.0.32". The DNS is a set of protocols and databases. The 
protocols define the syntax and semantics for a query language to ask 
questions about information located by DNS-style names. The 
databases are distributed and replicated. There is no dependence on 
a single central server, and each part of the database is provided in 
at least two servers. 


The assignment of the 32-bit IP addresses is a separate activity. IP 
addresses are delegated by the central Internet Registry to regional 
authorities (such as the RIPE NCC for Europe) and the network 
providers. 


To have a network number assigned please contact your network service 
provider or regional registration authority. To determine who this 
is (or as a last resort), you can contact the central Internet 
Registry at Hostmaster@INTERNIC.NET. 


In addition to translating names to addresses for hosts that are on 
the Internet, the DNS provides for registering DNS-style names for 
other hosts reachable (via electronic mail) through gateways or mail 
relays. The records for such name registrations point to an Internet 
host (one with an IP address) that acts as a mail forwarder for the 
registered host. For example, the host "bah.rochester.ny.us" is 
registered in the DNS with a pointer to the mail relay 
"relayl.uu.net". This type of pointer is called an MX record. 


This gives electronic mail users a uniform mail addressing syntax and 
avoids making users aware of the underlying network boundaries. 


The reason for the development of the domain system was growth in the 
Internet. The hostname to address mappings were maintained by the 
InterNIC in a single file, called HOSTS.TXT, which was FTP'd by all 
the hosts on the Internet. The network population was changing in 
character. The time-share hosts that made up the original ARPANET 
were being replaced with local networks of workstations. Local 
organizations were administering their own names and addresses, but 
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had to wait for the NIC to make changes in HOSTS.TXT to make the 
changes visible to the Internet at large. Organizations also wanted 
some local structure on the name space. The applications on the 
Internet were getting more sophisticated and creating a need for 
general purpose name service. The idea of a hierarchical name space, 
with the hierarchy roughly corresponding to organizational structure, 
and names using "." as the character to mark the boundary between 
hierarchy levels was developed. A design using a distributed 
database and generalized resources was implemented. 


The DNS provides standard formats for resource data, standard methods 
for querying the database, and standard methods for name servers to 
refresh local data from other name servers. 


1.2 Top-Level Domains 


The top-level domains in the DNS are EDU, COM, GOV, MIL, ORG, INT, 
and NET, and all the 2-letter country codes from the list of 
countries in ISO-3166. The establishment of new top-level domains is 
managed by the Internet Assigned Numbers Authority (IANA). The IANA 
may be contacted at IANA@ISI.EDU. 


Even though the original intention was that any educational 
institution anywhere in the world could be registered under the EDU 
domain, in practice, it has turned out with few exceptions, only 
those in the United States have registered under EDU, similarly with 
COM (for commercial). In other countries, everything is registered 
under the 2-letter country code, often with some subdivision. For 
example, in Korea (KR) the second level names are AC for academic 
community, CO for commercial, GO for government, and RE for research. 
However, each country may go its own way about organizing its domain, 
and many have. 


There are no current plans of putting all of the organizational 
domains EDU, GOV, COM, etc., under US. These name tokens are not 
used in the US Domain to avoid confusion. 


Currently, only four year colleges and universities are being 
registered in the EDU domain. All other schools are being registered 
in the US Domain. 


There are also concerns about the size of the other top-level domains 
(especially COM) and ideas are being considered for restructuring. 


Other names sometimes appear as top-level domain names. Some people 
have made up names in the DNS-style without coordinating or 
registering with the DNS management. Some names that typically 


appear are BITNET, UUCP, and two-letter codes for continents, such as 
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"NA" for North America (this conflicts with the official Internet 
code for Namibia). 


For example, the DNS-style name "KA7EEJ.CO.USA.NA" is used in the 
amateur radio network. These addresses are never supposed to show up 
on the Internet but they do occasionally. The amateur radio network 
people created their own naming scheme, and it interferes sometimes 
with Internet addresses. 


1.3 The US Domain 


The US Domain is an official top-level domain in the DNS of the 
Internet community. The domain administrators are Jon Postel and Ann 
Westine Cooper at the Information Sciences Institute of the 
University of Southern California (USC-ISI). 


US is the ISO-3166 2-letter country code for the United States and 
thus the US Domain is established as a top-level domain and 
registered with the InterNIC the same way other country domains are. 


Because organizations in the United States have registered primarily 
in the EDU and COM domains, little use was initially made of the US 
domain. In the past, the computers registered in the US Domain were 
primarily owned by small companies or individuals with computers at 
home. However, the US Domain has grown and currently registers hosts 
in federal government agencies, state government agencies, K12 
schools, community colleges, technical/vocational schools, private 
schools, libraries, city and county government agencies, to name a 
few. 


Initially, the administration of the US Domain was managed solely by 
the Domain Registrar. However, due to the increase in registrations, 
administration of subdomains is being delegated to others. 


Any computer in the United States may be registered in the US Domain. 
2. NAMING STRUCTURE 

The US Domain hierarchy is based on political geography. The basic 

name space under US is the state name space, then the "locality" name 


Space, (like a city, or county) then organization or computer name 
and so on. 


For example: 


BERKELEY.CA.US 
PORTLAND.WA.US 
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There is of course no problem with running out of names. 
The things that are named are individual computers. 


If you register now in one city and then move, the database can be 
updated with a new name in your new city, and a pointer can be set up 
from your old name to your new name. This type of pointer is called 
a CNAME record. 


The use of unregistered names is not effective and causes problems 
for other users. Inventing your own name and using it without 
registering is not a good idea. 


In addition to strictly geographically names, some special names are 
used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC, CITY, and 
COUNTY. Several new name spaces have been created, DNI, GEN, and 
TEC, and a minor change under the "locality" name space was made to 
the existing CITY and COUNTY subdomains by abbreviating them to CI 
and CO. A detailed description follows. 


Below US, Parallel to States: 


"FED" - This branch may be used for agencies of the federal 
government. For example: <org-name>.<city>.FED.US 
"DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was 


created directly under the top-level US. This branch is to be used 
for distributed national institutes; organizations that span state, 
regional, and other organizational boundaries; that are national in 
Scope, and have distributed facilities. For example: 
<org-name>.DNI.US. 


Name Space Within States: 


"locality" - cities, counties, parishes, and townships. Subdomains 
under the "locality" would be like CI.<city>.<state>.US, 
CO.<county>.<state>.US, or businesses. For example: 
Petville.Marvista.CA.US. 


"CI" - This branch is used for city government agencies and is a 
subdomain under the "locality" name (like Los Angeles). For example: 
Fire-Dept.CI.Los-Angeles.CA.US. 


"CO" - This branch is used for county government agencies and is a 


subdomain under the "locality" name (like Los Angeles). For example: 
Fire-Dept.CO.San-Diego.CA.US. 
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"K12" - This branch may be used for public school districts. A 
Special name "PVT" can be used in the place of a school district name 
for private schools. For example: <school-name>.K12.<state>.US and 


<school-name>.PVT.K12.<state>.US. 


"CC" - COMMUNITY COLLEGES - This branch was established for all state 
wide community colleges. For example: <school-name>.CC.<state>.US. 
"TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was 


established for technical and vocational schools and colleges. For 
example: <school-name>.TEC.<state>.US. 


"LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may 
be used for libraries only. For example: <lib-name>.LIB.<state>.US. 
"STATE" - This branch may be used for state government agencies. For 


example:  «org-name».STATE.«state».US. 


"GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things 
that don't fit easily into any other structure listed -- things that 
might fit in to something like ORG at the top-level. It is best not 
to use the same keywords (ORG, EDU, COM, etc.) that are used at the 
top-level to avoid confusion. GEN would be used for such things as, 
state-wide organizations, clubs, or domain parks. For example: 
<org-name>.GEN.<state-code>.US. 


十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 


VIEW OF SECOND LEVEL DOMAINS UNDER US 
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十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
SCHOOL AND LIBRARY VIEW 


+----- + 
| cal 
+ 一 一 一 一 一 + 
| 
十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 
| | | | 
+----- + +----- + 十 一 一 一 一 一 + 十 一 一 一 一 一 一 一 一 一 一 一 一 一 + + 一 一 一 一 一 + 
| K12 | | cc | | tec | | Los ANGELES | | LIB | 
+ 一 一 一 一 一 + + 一 一 一 一 一 + +----- + 十 一 一 一 一 一 一 一 一 一 一 一 一 一 + + 一 一 一 一 一 + 
FOR /\\ /\\ MN AS 
+ 一 一 一 一 一 一 一 一 + +---+ +---+ 十 一 一 一 一 一 一 一 一 + 十 一 一 一 一 一 一 一 一 一 一 + + 一 一 一 一 一 一 + 
|sch dist| |Pvr| |soc| |wm TRADE| |pvt school| | MALIBU | 
+ 一 一 一 一 一 一 一 一 + +---+ +---+ 十 一 一 一 一 一 一 一 一 + 十 一 一 一 一 一 一 一 一 一 一 + + 一 一 一 一 一 一 + 
MN /\\ 
+ 一 一 一 一 一 一 一 一 + +-------- + 
[sch name| |sch name 
+ 一 一 一 一 一 一 一 一 + +-------- + 


十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 


VIEW OF STATE, REGIONAL, and GENERAL AGENCIES 


+----- + 

| ca | 

+ 一 一 一 一 一 + 

| 
十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 
| | | 
+ 一 一 一 一 一 一 一 + + 一 一 一 一 一 一 一 一 + + 一 一 一 一 一 + 
| STATE | |DISTRICT | | GEN | 
4+------- + + 一 一 一 一 一 一 一 一 + + 一 一 一 一 一 + 
NN FARK NN 

4+-------- + +------ + +--------- + 
| CALTRANS | | SCAQMD | |domain pk| 
一 一 一 一 一 一 一 一 一 + 十 一 一 一 一 一 一 十 4+---------+ 
ei 一 一 一 一 一 + 
| TCEW100E | 
+ 一 一 一 一 一 一 一 一 + 


十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
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十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 


VIEW OF LOCALITY 


+ 一 一 一 一 一 + 
| ca | 
+ 一 一 一 一 一 + 
| 
十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 

十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 

| LOS ANGELES | | SANTA MONICA | 

十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 二 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 

/ | | AN | /\\ 

/ | | | | | 
十 一 一 一 十 +--+ +--+ 十 一 一 一 一 一 一 一 一 一 一 一 + 十 一 一 十 十 一 一 一 十 
|bus| |cr| |co] | pvt school |cr| |bus | 
十 一 一 一 十 +--+ +--+ 十 一 一 一 一 一 一 一 一 一 一 一 + 十 一 一 十 十 一 一 一 十 

/\ | | 
£N | + 一 一 一 一 一 一 一 一 一 一 一 一 + 
/ \ | HARBOR GUARD | 
/ \ | ce ae a + 
+----- + 十 一 一 一 一 一 + + 一 一 一 一 一 + 十 一 一 一 一 十 
|FIRE | |ADMIN| |PARKS| |FIRE| 
+ 一 一 一 一 一 + +----- + + 一 一 一 一 一 + 十 一 一 一 一 十 


十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
2.1 State Codes 


The state codes are the two letter US Postal abbreviations. For 
example: "CA" California. 


2.2 Locality Names 
Within the state name space there are "locality" names, some may be 
cities, some may be counties, some may be local names, but not 


incorporated entities. 


Registered names under "locality" could be like: 


<hostname>.CI.<locality>.<state>.US ==> city gov't agency 
<hostname>.CO.<locality>.<state>.US, ==> county gov’t agency 
<hostname>.<locality>.<state>.US ==> businesses 


In the cases where the locality name is a county, there is a branch 
under the locality name, called "county" or "CO", that is used by the 
county government. Businesses are registered directly under the 
locality name. 
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Under the city locality name space there is a "city" or "CI" branch 
for city government agencies. As usual, businesses and private 
Schools may register directly under the city name. 


In the case where there is both a county and a city with the same 
locality name there is no problem, since the names will be unique 
with the "CO" or "CI" keyword. In our area the county has a fire 
department and the city has its own fire department. They could have 
names like: 


Fire-Dept.CI.Los-Angeles.CA.US 
Fire-Dept.CO.Los-Angeles.CA.US 


Cities may be named (designated) by their full name (spelled out with 
hyphens replacing spaces (e.g., Los-Angeles or Fort-Collins), or by a 
city code. The first choice is the full city name. In some cases it 
may be appropriate to use the well-known city abbreviation known 
throughout a locality. However, it is very desirable that all users 
in the same city use the same designator for the city. That is, any 
particular locality should have just one DNS name. 


Some users would like names associated with a greater metropolitan 
area or region like the "Bay Area" or "Tri-Cities". One problem with 
this is that these names are not necessarily unique within a state. 
The best thing to do in this case is to use the larger metropolitan 
city in your hostname. Cities and counties are used. 


Should all the names be obvious? Trying to do this is desirable and 
also impossible. There will come a point when the obviously right 
name for an organization is already taken. As the system grows this 
will happen with increasing frequency. While ease of use to the end 
user is desirable, a higher priority must be placed on having a 
system that operates. This means that the manageability of the 
System must have high consideration. 


The reason the DNS was created was to subdivide the problem of 
maintaining a list of hosts in the Internet into manageable portions. 


The happy result is that this subdivision makes name uniqueness 
easier and promotes logical grouping. What is a "logical grouping" 
though, always depends on the viewer. 


Many levels of delegation are needed to keep the zone files 


manageable. Many sections of the name space are needed to allow 
unique names to be easily added. 
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Way back in the olden days, when the Internet was invented, some 
thought that an 8-bit network number would be more than enough to 
number all the networks that would ever exist. Today, there are over 
10,000 networks operating in the Internet, and arguments are made 
about the doubling time being 2 years versus 4 years. 


One concern is that things will continue to grow dramatically, and 
this will require more subdivision of the domain name management. 
Maybe the plan for the US Domain is overkill on growth planning, but 
there has never been overplanning for growth yet. 


When things are bigger, names have to be longer. There is an 
argument that with only 8-character names, and in each position allow 
a-z, 0-9, and -, you get 37**8 = 3,512,479,453,921 or 3.5 trillion 
possible names. It is a great argument, but how many of us want 
names like "xs4gp-7q". It is like license plate numbers, sure some 
people get the name they want on a vanity plate, but a lot more 
people who want something specific on a vanity plate can’t get it 
because someone else got it first. Structure and longer names also 
let more people get their "obviously right" name. 


2.3 Schools 


K12 schools are connecting to the Internet and registering in the 
Internet DNS. A decision has been made by the IANA (after 
consultation with the new InterNIC Internet Registry and the Federal 
Networking Council (FNC)) to direct these school registrations to the 
US domain using the naming structure described here. 


There is a need for competent, experienced, volunteers to come 
forward to act as third and perhaps fourth level registries and to 
operate delegated portions of the DNS. 


There are two reasons for registering schools in the US Domain. (1) 
uniqueness of names, and (2) management of the database. 


1. Name Uniqueness: 


There are many "Washington" high schools, only one can be 
"Washington.EDU" (actually none can be, since that name is used 
by a University. There will be many name conflicts if all 
schools attempt to register directly under EDU. 


In addition, in some districts, the same school name is used at 
different levels, for example, Washington Elementary School and 
Washington High School. We suggest that when necessary, the 
keywords "Elementary", "Middle", and "High" be used to 
distinguish these schools. These keywords would only be used 
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when they are needed, if the school’s name is unique without 
such keywords, don’t use them. 


2. Database Management: 


One goal of the DNS is to divide up the management of the name 
database in to small pieces. Each piece (or "zone" in DNS 
terminology) could be managed by a distinct administrator. 
Adding all the high schools to the EDU domain will make the 
already large zone file for EDU even larger, possibly to the 
point of being unmanageable. 


For both these reasons it is necessary to introduce structure into 
names. Structure provides a basis for making common names unique in 
context, and for dividing the management responsibility. 


The US Domain has a framework established and has registered many 
schools already in this structured scheme. The general form is: 


<school>.<district>.K12.<state>.US. 
For example: Hamilton.LA-Unified.K12.CA.US 


Public schools are usually organized by districts which can be larger 
or smaller than a city or county. For example, the Portland school 
district in Oregon, is in three or four counties. Each of those 
counties also has non-Portland districts. 


It makes sense to name schools within districts. However districts 
often have the same name as a city or county so there has to be a way 
to distinguish a public school district name from some other type of 
locality name. The keyword "K12" is used for this. 


For example, typical K12 school names currently used are: 


IVY.PRS.K12.NJ.US 
DMHS.JCPS.K12.KY.US 
OHS.EUNION.K12.CA.US 
BOHS.BREA.K12.CA.US 


These names are generally longer than the old alternative of shorter 
names in the EDU domain, but that would not have lasted long without 
a significant number of schools finding that their "obviously 
correct" name has already been used by some other school. 
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When there are many things to name some of the names will be long. 
In some cases there may be appropriate abbreviations that can be 
used. For example Hamilton High School in Los Angeles could be: 


Hami.Hi.LA.K12.CA.US 


If a school has a number of PCs, then each PC should have a name. 
Suppose they are named "alpha", "beta", ... then if they belong to a 
School named "Lincoln.High.Lakewood.K12.CA.US" their names would be: 


alpha.Lincoln.High.Lakewood.K12.CA.US. 
beta.Lincoln.High.Lakewood.K12.CA.US 


The K12 subdomain provides two points at which to delegate a branch 
of the database to distinct administrators -- the K12 Administrator 
for each state, and the district administrator for each district 
within a state. 


The US Domain Administrator will delegate a branch of the US domain 
to an appropriate party. In some cases, this may be a particular 
school, a school district, or ever all of K12 for a state. 


The responsibility for managing a K12 branch or sub-branch may be 
delegated to an appropriate volunteer. We envision that such 
delegations of the schools' DNS service may eventually migrate to 
Someone else "more appropriate" from an administrative organizational 
point of view. The "obvious" state agency to manage the schools' DNS 
branch may take some time to get up to speed on Internetting. In the 
meantime, we can have the more advanced schools up and running. 


Special Schools and Service Units 


In many states, there are special schools that are not in districts 
that are run directly by the state or by consortiums. There are also 
service units that provide "educational services" ranging from books 
and computers to janitorial supplies and building maintenance. Often 
these service units do not have a one-to-one relationship with 
districts. 


There is some concern about naming these schools and service units 
within the naming structure for schools established in this memo. 
There are several possibilities. For a state with many service units 
creating a "pseudo district" ESU (or whatever, the common terminology 
is in that state) is a possibility. For example, the Johnson service 
unit could be JOHNSON.ESU.K12.CA.US. For a state with a few such 
Service units (and avoiding conflicts with district names) the 
service units could be directly under K12. For example, 
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TIES.K12.MN.US. 


The special public funded schools can be handled in a similar 


fashion. If there are many special schools in a state, a "pseudo 
district" should be established and all the special schools listed 
under it. For example, suppose there is a "pseudo district" in 


Massachusetts called SPCL, and there is a special school called the 
Progressive Computer Institute, then that school could have the name 
PCI.SPCL.K12.MA.US. If there are only a few special schools, they 
can be listed directly under K12 (avoiding name conflicts with 
district names). For example, the California Academy of Math and 
Science is CAMS.K12.CA.US. CAMS is sponsored by seven schools, the 
California Department of Education, and a University. 


"PVT" Private Schools 


Private schools may be thought of as businesses. Public schools are 
in districts, and districts provide a natural organizational 
Structure for naming and delegation. For private schools there are 
no districts and they really do operate like businesses. But, many 
people are upset to think about their children in a private school 
being in a business category and not in K12 with the rest of the 
children. To accommodate both public and private schools, in each 
state's K12 branch, we've added an artificial district called private 
or "PVT". This gives a private school the option of registering like 
a business under "locality" or in the PVT.K12.<state-code>.US branch. 


For example: 


Crossroads.PVT.K12.CA.US 
Crossroads-Santa-Monica.CA.US 


A public school "Oak High" in the "Woodward" school district in 
California would have a name like "Oak-High.Woodward.K12.CA.US". 


A private school "Old Trail" in Pasadena, California could have the 
«locality» based name "Old-Trail.Pasadena.CA.US" or the private 
School base name "Old-Trail.PVT.K12.CA.US". 


Some suggest that for private schools instead of a special pseudo 
district PVT to use a locality name. One reason to use district 
names is that, in time, it seems likely that school district 
administrators will take over the operation of the DNS for their 
district. One needs to be able to delegate at that branch point. 

One implication of delegation is that the delegatee is now in charge 
of a chunk of the name space and will be registering new names. To 
keep names unique one can't have two different people registering new 
things below identically named branches. 
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For example, if there is a school district named Pasadena and a city 
named Pasadena, the branch of the name space PASADENA.K12.CA.US might 
be delegated to the administrator of that public school district. If 
a private school in Pasadena wanted to be registered in the DNS, it 
would have to get the public school district administrator to do it 
(perhaps unlikely) or not be in the K12 branch at all (unless there 
is the PVT pseudo district). 


So, if private schools are registered by 
<school>.<locality>.K12.<state-code>.US and public schools are 
registered by <school>.<district>.K12.<state-code>.US, there can't be 
any locality names that are the same as district names or the 
delegation of these will get very tricky later. 


If it is all done by locality names rather than district names, and 
public and private schools are mixed together, then finding an 
appropriate party to delegate the locality to may be difficult. 


Another suggestion was that private schools be registered directly 
under K12, while public schools must be under a district under K12. 
This would require the operator of the K12 branch to register all 
districts and private schools himself (checking for name uniqueness), 
he couldn't easily delegate the registration of the private schools 
to anyone else. 


Community Colleges and Technical Schools 


To distinguish Community Colleges and Technical/Vocational schools, 
the keywords "CC" and "TEC" have been created. 


Some School Examples 


Hamilton.High.LA-Unified.K12.CA.US <== a public school 
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <== a public school 
John-Muir.Middle.Santa-Monica.K12.CA.US <== a public school 
Crossroads-School.Santa-Monica.CA.US <== a private school 
SMCC.CC.CA.US <== a community college 
TECMCC.CC.CA.US <== a community college 
Brick-and-Basket-Institute.TEC.CA.US <== a technical college 
Northridge.CSU.STATE.CA.US <== a state university 
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2.4 State Agencies 


Several states are setting up networks to interconnect the offices of 
state government agencies. The hosts in such networks should be 
registered under the STATE.<state-code>.US branch. 


A US Domain name space has been established for the state government 
agencies. For example, in the State of Minnesota, the subdomain is 
STATE.MN.US. 


State Agencies: 


Senate.STATE.MN.US <== State Senate 
MDH.STATE.MN.US <== Dept. of Health 
CALTRANS .STATE.CA.US <== Dept. of Transportation 
DMV.STATE.CA.US <== Dept. of Motor Vehicles 


2.5 Federal Agencies 


A federal name space has been established for the federal government 
agencies. For example, the subdomain for the Federal Reserve Bank of 
Minneapolis is MNPL.FRB.FED.US. Other examples are listed below. 


Federal Government Agencies: 


Senate.FED.US <==== US Senate 

DOD.FED.US <==== US Defense Dept. 

USPS.FED.US <==== US Postal Service 

VA.FED.US <==== US Veterans Administration 
IRS.FED.US <==== US Internal Revenue Service 
Yosemite.NPS.Interior.FED.US <==== A Federal agency 


2.6 Distributed National Institutes 

The "DNI" branch was created directly under the top-level US. This 
is to be used for organizations that span state, regional, and other 
organizational boundaries; are national in scope, and have 


distributed facilities. An example would be: 


Distributed National Institutes: 


MetaCenter.DNI.US <==== The MetaCenter Supercomputer Centers 
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The MetaCenter domain encompasses the four NSF sponsored 
supercomputer centers. These are: 


San Diego Supercomputer Center (SDSC) 

National Center for Supercomputing Applications (NCSA) 
Pittsburgh Supercomputing Center (PSC) 

Cornell Theory Center (CTC) 


The MetaCenter Network will enable applications and services like 
file systems and archival storage to be operated in a distributed 
fashion; thus, allowing the resources at the four centers to appear 
integrated and "seamless" to users of the centers. 


2.7 General Independent Entities 


This name space was created for organizations that don't really fit 
anywhere else, such as state-wide associations, clubs, and "domain 
parks". Think of this as the miscellaneous category. 


The examples are state-wide clubs. For example, the Garden Club of 
Arizona, might want to be "GARDEN.GEN.AZ.US". Such a club has 
membership from all over the state and is not associated with any one 
city (or locality). Another example is "domain parks" that have been 
established up-to-now as entities in ORG. For example, there is 
"LONESTAR.ORG", which is a kind of computer club in Texas that has 
lots of dial-in computers registered. In the US Domain such an 
entity might have a name like "LONESTAR.GEN.TX.US". 


The organizations registered in GEN may typically be non-profit 
entities. These organizations don't fit in a «locality» and are not 
a school, library, or state agency. Ordinary businesses are not 
registered in GEN. 


Some suggest that these kinds of organizations are just like all the 
other things and ought to be registered under some «locality». This 
may be true, but sometimes one just can't find any way to convince 
the applicant that it is the right thing to do. One can argue that 
any organization has to have a headquarters, or an office, or 
something about it that is in a fixed place, and thus the 
organization could be registered in that place. 


Some suggest that no token is needed, these entities could be 
directly under the <state-code>. The problem with not having a 
token, is that you can't delegate the responsibility for registering 
these entities to someone separate from whoever is responsible for 
the <state-code>. You want to be able to delegate for both name- 
uniqueness reasons, and operational management reasons. Having a 
token there makes both easy. 
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General Independent Entities: 


CAL-Comp-Club.GEN.CA.US <==== The Computer Club of California 
2.8 Examples of Names 


For small entities like individuals or small businesses, there is 
usually no problem with selecting locality based names. 


For example:  Zuckys.Santa-Monica.CA.US 


For large entities like large corporations with multiple 
facilities in several cities or states this often seems like an 
unreasonable constraint (especially when compared with the 
alternative of registering directly in the COM domain). However, 
a company does have a headquarters office in a particular locality 
and so could register with that name. Example: IBM.Armonk.NY.US 


PRIVATE (business or individual) 


Camp-Curry.Yosemite.CA.US <==== a business 
IBM.Armonk.NY.US <==== a business 
Dogwood.atl.GA.US <==== a business 
Geo-Petrellis.Culver-City.CA.US <==== a restaurant 
Zuckys.Santa-Monica.CA.US <==== a restaurant 
Joe-Josts.Long-Beach.CA.US <==== a bar 
Holodek.Santa-Cruz.CA.US <==== a personal computer 
FEDERAL 

Senate.FED.US <==== US Senate 

DOD.FED.US <==== US Defense Dept. 

DOT.FED.US <==== US Transportation Dept. 
USPS.FED.US <==== US Postal Service 

VA.FED.US <==== US Veterans Administration 
IRS.FED.US <==== US Internal Revenue Service 
Yosemite.NPS.Interior.FED.US <==== a federal agency 
MNPL.FRB.FED.US. <==== US Fed. Reserve Bank of Minneapolis 
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STATE 

Senate.STATE.MN.US <==== state Senate 

House.STATE.MN.US <==== state House of Reps 
MDH.STATE.MN.US <==== state Health Dept. 
HUD.STATE.CA.US <==== state House and Urban Dev. Dept. 
DOT.STATE.MN.US <==== state Transportation Dept. 
CALTRANS .STATE .CA.US <==== state Transportation Dept. 
DMV.STATE.CA.US <==== state Motor Vehicles Dept. 
Culver-City.DMV.STATE.CA.US <==== a local office of DMV 


DNI (distributed national Institutes) 


METACENTER.DNI.US <==== a distributed nat'l Inst. 


GEN (General Independent Entities) 


GARDEN.GEN.AZ.US <==== a garden club of Arizona 


CITY | CI | COUNTY | co (locality) 


Parks.CI.Culver-City.CA.US <==== a city department 
Fire-Dept.CI.Los-Angeles.CA.US <==== a city department 
Fire-Dept.CO.Los-Angeles.CA.US <==== a county department 
Planning.CO.Fulton.GA.US. <==== a county department 
Main.Library.CI.Los-Angeles.CA.US <==== a city department 
MDR.Library.CO.Los-Angeles.CA.US <==== a county department 
TOWNSHIP | PARISH (locality) 

Police.TOWNSHIP.Green.OH.US <==== a township department 
Administration.PARISH.Lafayette.LA.US <==== a parish department 
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DISTRICT LIBRARY (agency) 


SCAQMD .DISTRICT.CA.US <==== a regional district 
Bunker-Hill-Improvement.DISTRICT.LA.CA.US <==== a local district 
Huntington.LIB.CA.US <==== a private library 
Venice.LA-City.LIB.CA.US <==== a city library 
MDR.LA-County.LIB.CA.US <==== a county library 

K12 | PRIVATE SCHOOLS (PVT) | cc | TEC 
Hamilton.High.LA-Unified.K12.CA.US <==== a public school 
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <==== a public K12 school 
John-Muir.Middle.Santa-Monica.K12.CA.US <==== a public K12 school 
Culver-High.CCSD.K12.CA.US <==== a public K12 school 
St-Monica.High.Santa-Monica.CA.US <==== a private school 
Crossroads-School.Santa-Monica.CA.US <==== a private school 
Mary-Ellens.Montessori-School.LA.CA.US <==== a private school 
Progress-Learning-Center.PVT.K12.CA.US <==== a private school 
SMCC.Santa-Monica.CC.CA.US <==== a public community college 
Trade-Tech.Los-Angeles.CC.CA.US <==== a public community college 
Valley.Los-Angeles.CC.CA.US <==== a public community college 
Brick-and-Basket-Institute.TEC.CA.US <== a technical college 


When appropriate, subdomains are delegated and partioned in 
various categories, such as: 


<locality>.<state>.US = city/locality based names 
K12.<state>.US = kindergarten thru 12th grade 
PVT.K12.«state.US = private kindergarten thru 12th grade 
CC.<state>.US = community colleges 
TEC.<state>.US = technical or vocational schools 
LIB.<state>.US = libraries 
STATE.<state>.US = state government agencies 
<org-name>.FED.US = federal government agencies 
<org-name>.DNI.US = distributed national institutes 
<org-name>.GEN.<state>.US. = statewide assoc,clubs, domain parks 


The Appendix-I contains the current US Domain Names BNF. 
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3. REGISTRATION 


There are two types of registrations (1) Delegation, where a branch 
of the US Domain is delegated to an organization running name servers 
to support that branch; or (2) Direct Registration, in which the 
information is put directly into the main database. 


In Direct Registration there are two cases: (a) an IP-host (with an 
IP address), and (b) non-IP host (for example, a UUCP host). Any 
particular registration will involve any one of these three 
situations. 


3.1 Requirements 


Anyone requesting to register a host in the US Domain is sent a copy 
of the "Instructions for the US Domain Template", and must fill out a 
US Domain template. 


The US Domain template, is similar to the InterNIC Domain template, 
but it is not the same. To request a copy of the US Domain template, 
send a message to the US Domain registrar (us-domain@isi.edu). 


If you are registering a name in a delegated zone, please register 
with the contact for that zone. You can FTP the file "in-notes/us- 
domain-delegated.txt" from venera.isi.edu, via anonymous FTP. This 
information is also available via email from RFC-INFO@ISI.EDU 
(include as the only text in the message 

"Help: us_domain_delegated_domains"). 


The key people must have electronic mailboxes (that work). Please 
provide all the information indicated in the "Administrator" and 
"Technical Contact" slots. 


The administrator will be the point of contact for any administrative 
and policy questions about the domain. The administrator is usually 
the person who manages the organization being registered. 


The technical contact can also be administrator, or the systems 
person, or someone who is familiar with the technical details of the 
Internet. The technical contact should have a valid working email 
address. This is necessary in case something goes wrong. 


It is important that your "Return-Path" and "From" field indicate an 


Internet-style address.  UUCP-style addresses such as "hostl!user" 
will not work. This is fine within the UUCP world, but not the 
Internet. If you want people on the Internet to be able to send mail 


to you, your return path needs to be an Internet-style address such 
as: hostl!user@Internet.gateway.host or user@Internet.gateway.host. 
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It is also possible to register through one of the Internet service 
providers that have established working relationships with the US 
Domain Administrator. 


If everything checks out, the turn around time for registering a host 
is usually a few days. The name servers are updated anywhere from 12 
to 24 hours later. 


There are two ways to be registered in the US Domain, directly, or by 
delegation. 


3.2 Direct Entries 


Direct entry in the database of the US Domain appeals most to 
individuals and small companies. You may fill out the application 
and send it directly to the US Domain Administrator. If you are in 
an area where the zone is delegated to someone else your request will 
be forwarded to the zone administrator for your registration. Or, 
you may send the form directly to the manager of a delegated zone 
(see Section 3.1). 


3.2.1 IP-Hosts 


These are hosts with IP addresses which correspond to "A" records in 
the DNS database. 


3.2.2 Non-IP Hosts 


Many applicants have hosts in the UUCP world. Some are one hop away, 
some two and three hops away from their "Internet Forwarder", this is 
acceptable. What is important is getting an Internet host to be your 
forwarder. If you do not already have an Internet forwarder, there 
are several businesses that provide this service for a fee, such as 
UUNET.UU.NET (postmaster@uunet.uu.net), PSI (postmaster@UU2.PSI.COM) 
and CERFNET (help@cerf.net). Sometimes local colleges in your area 
are already on the Internet and may be willing to act as an Internet 
Forwarder. You would need to work this out with the systems 
administrator as we cannot make these arrangements for you. 


Although we work with UUCP service providers, the Internet US Domain 
registration is not affiliated with the registration of UUCP Map 


entries. The UUCP map entry does not provide us with sufficient 
information. If you do not have a copy of the US Domain 
questionnaire template, please send a message to: us-domain@isi.edu 
and request one. See Appendix-II. 
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The example below is not an appropriate registration for the US Domain. 


#N starl 

#S Amiga 2500; AmigaDOS 2.04; Dillon’s AmigaUUCP 1.15D 
#0 Starlight BBS 

#C Stephen Baker 

#E starl!sbaker 

#T +1 305 378 1161 

#P 1107 SW 200th St #303B Miami, Fl. 33157 

#L 25 47 N / 88 10 W [city] 


#R 

#U mthvax 

#W starl!sbaker (Stephen Baker); Mon Feb 24 19:58:24 EST 1992 
starl mthvax (DAILY) 


If you are registering your host as a central site for a USENET group 
where other UUCP sites will feed from you, that’s fine. These UUCP 
sites do not need to register. If however, the other sites become a 
subdomain of your hostname, then we will need to register them 
individually or add a wildcard record. (See Section 4.4. Wildcards). 


For example: bah.rochester.ny.us 
hostl.bah.rochester.ny.us 
host2.bah.rochester.ny.us 


To use US Domain names for non-IP hosts, there must be a forwarder 
host that is an IP host. There must be an administrative agreement 


and a technical procedure for relaying mail between the non-IP host 
and the forwarder host. 


Your host is not an IP host but does talk directly with a host that 
is an IP host. 


"Forwarder" must be an IP host on the Internet. 


You must ask "forwarder" if they are willing to be the Internet 
forwarder for "your-host". 


In the US Domain of the DNS data base there must be an entry like 


this: 
"your-host" MX 10 "forwarder" 
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This must be entered by the US Domain Administrator. 


In the "forwarder" routing tables there must be information about 
"your-host" with a rule like: If I see mail for "your-host" I will 
send it via uucp by calling phone number "123-4567". 


Case 2 
In this case your hosts talks to another host that ... that talks to 
an IP host. In other words, there are multiple hops between your host 
and the Internet. 
foo See eR SSS SSS st + 

+ 一 一 一 一 一 一 一 一 一 一 + + 一 一 一 一 一 一 一 一 一 + | | 
|path-host |---UUCP----- forwarder | ----IP/TCP--| INTERNET | 
+ 一 一 一 一 一 一 一 一 一 一 + + 一 一 一 一 一 一 一 一 一 + | | 

| 二 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 

ar 

Ho + 
| your-host | 
+---------- + 


"Forwarder" must be an IP host on the Internet. 


You must ask "forwarder" if they are willing to be the Internet 
Forwarder for "Your-Host". You must ask "path-host" to relay your 
mail. 


In the US Domain of the DNS Database there must be an entry like this: 
"your-host" MX 10 "forwarder" 
This must be entered by the US Domain Administrator. 


In the "forwarder" routing tables there must be information about 
"your-host" with a rule like: If I see mail for "your-host" I will 
send it via UUCP to "path-host" by calling phone number "123-4567". 
and "path-host" must also know how to relay the mail to "your-host". 


Note: It is assumed that "path-host" is already MXed to "forwarder". 
It is not appropriate to ask to MX "your-host" to "path-host" (this 
is sometimes called double MXing). The host on the right hand side 
of an MX entry must be a host on the Internet with an IP address 
(e.g., 128.9.2.32). 
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3.3 Delegated Subdomains 


Many branches of the US Domain are delegated. There must be a 
knowledgeable and competent technical contact, familiar with the 
Internet DNS. This requirement is easily satisified if the technical 
contact already runs some other name servers. 


Examples of delegations are K12.TX.US for the Kindergarten through 
12th Grade public schools in Texas, the locality "berkeley.ca.us", or 
the LIB.MN.US branch for the libraries in Minnesota. 


The administrator of the US Domain is responsible for the assignment 
of all the DNS names that end with ".US". Of course, one person or 
even one group can’t handle all this in the long run so portions of 
the name space are delegated to others. 


The major concern in selecting a designated manager for a domain is 
that it be able to carry out the necessary responsibilities, and have 
the ability to do an equitable, just, honest, and competent job. 


The key requirement is that for each domain there be a designated 
manager for supervising that domain’s name space. 


These designated authorities are trustees for the delegated domain, 
and have a duty to serve the community. 


The designated manager is the trustee of the domain for the domain 
itself and the global Internet community. 


Concerns about "rights" and "ownership" of domains are inappropriate. 
It is appropriate to be concerned about "responsibilities" and 
"service" to the community. 


The designated manager must be equitable to all groups in the domain 
that request domain names. 


This means that the same rules are applied to all requests. All 
requests must be processed in a nondiscriminatory fashion, and 
academic and commercial (and other) users are treated on an equal 
basis. No bias shall be shown regarding requests that may come from 
customers of some other business related to the manager -- e.g., no 
preferential service for customers of a particular data network 
provider. There can be no requirement that a particular mail system 
(or other application), protocol, or product be used. 


There are no requirements on subdomains beyond the requirements on 
higher-level domains themselves. That is, the requirements are 
applied recursively. In particular, all subdomains shall be allowed 
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to operate their own domain name servers, providing in them whatever 
information the subdomain manager sees fit (as long as it is true and 
correct). 


Significantly interested parties in the domain should agree that the 
designated manager is the appropriate party. 


The US Domain Administrator tries to have any contending parties 
reach agreement among themselves, and generally takes no action to 
change things unless all the contending parties agree; only in cases 
where the designated manager has substantially neglected their 
responsibilities would the US Domain Administrator step in. 


The designated manager must do a satisfactory job of operating the 
DNS service for the domain. 


That is, the actual management of the assigning of domain names, 
delegating subdomains and operating name servers must be done with 
technical competence. This includes keeping the US Domain 
Administrator or other higher-level domain managers advised of the 
status of the domain, responding to requests in a timely manner, and 
operating the database with accuracy, robustness, and resilience. 


There must be a primary and a secondary name server that have IP 
connectivity to the Internet and can be easily checked for 
operational status and database accuracy by the US Domain 
Administrator. 


One of the aspects of having two name servers for each domain (or 
zone), is for robustness. One concern under this heading is that the 
name service not go out entirely if there is a local power failure 
(earthquake, tornado, or other disaster). 


Name Servers should be in distinctly separate physical locations. It 
is appropriate to have more than two name servers, but there must be 
at least two. 


For any transfer of the designated manager trusteeship from one 
organization to another, the higher-level domain manager must receive 
communications from both the old organization and the new 
organization that assures the US Domain Administrator that the 
transfer in mutually agreed, and that the new organization 
understands its responsibilities. 


It is also very helpful for the US Domain Administrator to receive 


communications from other parties that may be concerned or affected 
by the transfer. 


Cooper & Postel [Page 25] 


RFC 1480 The US Domain June 1993 


Delegation of cities, companies within cities, schools (K12), 
community colleges (CC), libraries (LIB), state government (STATE), 
and federal government agencies (FED), etc., is acceptable and 
practical. 


For a delegated portion of the name space, for example a city, no 
alterations can be made to that name, no abbreviations added, etc. 
unless applied for. 


Sometimes there may be two people running name servers in the same 
city because different portions of the name space has been delegated 
to them. For example, someone may be delegated the <city>.<state>.US 
name space, and someone else from a state government agency may have 
the .STATE.<state>.US, portion. For example, Fred may run the name 
servers for Sacramento.CA.US and Joe may run the name servers for 
STATE.CA.US in Sacramento. 


If a company would like to have wildcard records added, or run their 
own name servers in a city that we have delegated name space to, this 
is acceptable. 


Delegation of the whole State name space is not yet implemented. The 
delegated part of the name space is in the form of: 


.<locality>.<state>.US. 
.CI.<locality>.<state>.US. 
.CO.<locality>.<state>.US. 

.STATE.<State>.US. 
.K12.<state>.US. 
PVT.K12.<state>.US. 
.CC.<state>.US. 
.TEC.«state».US. 
.LIB.<state>.US. 
.GEN.<state>.US. 
.DNI.US. 

.FED.US. 


3.3.1. Delegation Requirements 


When a subdomain is delegated, the following requirements must be 
met: 


1) There must be a knowledgeable and competent technical contact, 
familiar with the Internet DNS. This requirement is easily 
satisified if the technical contact already runs some other 
name servers. 
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2) Organizations requesting delegations must provide at least two 
independent (robust and reliable) DNS name servers in 
physically separate locations on the Internet. 


3) The subdomain must accept all applicants on an equal basis. 


4) The subdomain must provide timely processing of requests. To 
do this, it is helpful to have several individuals 
knowledgeable about the procedures so that the operations are 
not delayed due to one persons unavailability (for example, by 
being on vacation). 


5) The subdomain manager must tell the US Domain Administrator 
when there are changes in the name servers that should be 
reflected in the US Domain zone files, or changes in the 
contact information. 


K12 Administrators 


In the long term, registering schools will be a big job. So you 
need to have in mind delegating parts of the work to various 
School districts. If you can delegate every school district in 
the state then you are finished, except for checking that they are 
all operating correctly. However, initially you will have quite a 
bit to do with educating people, helping them choose names and 
getting name servers arranged. You are responsible for seeing 
that the naming of schools follow the guidelines suggested in this 
memo. 


All K12 Administrators will initially be responsible for managing 
the "pseudo district" PVT for private schools. Private schools 
have the option of registering as <school-name>.PVT.K12.<state>.US 
or as a business under the city based names. 


Locality Administrators 


If you have been delegated a locality subdomain, you will be 
responsible for registering not only businesses directly under the 
locality, but city and county agencies under the "CI" and "CO" 
branches. When appropriate these branches should be delegated. 


If you want, you may spell out "CITY" instead of "CI" or "COUNTY" 
instead of "CO", but you must be consistent and use only one or 
the other in a given locality. The whole city government should 
be under one branch. 
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WHOIS Database 


Only the second and third level delegated name spaces will be 
entered in the WHOIS database. For example, K12.CA.US would have 
an entry in WHOIS. Anything under K12.CA.US will not be listed. 
The US Domain Administrator will send the information that you 
supplied on your US Domain template to the InterNIC. It is the 
hope that in the future, each delegated subdomain will provide 
their own WHOIS directory database for their branch. 

3.3.2 Delegation Procedures 

The procedure that is followed when a subdomain is delegated includes 

the following steps: 


1) Evaluate the technical contact’s experience with DNS. Make 
sure there is a need for the proposed delegation. Make sure 
the technical contact has the information about the US Domain 
and the suggested naming structure. Two contacts with email 
addresses are necessary in case something goes wrong. 


2) Add the new technical contact to the "us-dom-adm" mailing list 
for distributing updates concerning the US Domain policies and 
procedures. 


3) Delete any hosts from our zone file that belongs in the newly 
delegated subdomain and make sure they now have the hosts in 
their zone file. 


4) Send them a copy of the zone file so their initial zone file 
is identical to ours. For example: 


mil.wi.us. 69582 SOA spool.mu.edu. 
manager.spool.mu.edu. ( 

930119 ;serial 

28800 ;refresh 

14400 ;retry 

3600000 ;expire 

86400 ) ;minim 
mil.wi.us. 69582 NS spool.mu.edu. 
spool.mu.edu. 85483 A 134.48.1.31 
mil.wi.us. 69582 NS sophie.mscs.mu.edu. 
sophie.mscs.mu.edu. 85483 A 134.48.4.6 
solaria.mil.wi.us. 69582 HINFO Sun 3/60 SunOs 
solaria.mil.wi.us. 69582 MX 10 spool.mu.edu. 
nthomas.mil.wi.us. 69582 HINFO 386 Clone DOS 
nthomas.mil.wi.us. 69582 MX 10 spool.mu.edu. 
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rwmke.mil.wi.us. 69582 HINFO UNIX PC UNIX 
rwmke.mil.wi.us. 69582 MX 10 spool.mu.edu. 
milestn.mil.wi.us. 69582 MX 10 spool.mu.edu. 
nrunner.mil.wi.us. 69582 HINFO MacIntosh System 7 
nrunner.mil.wi.us. 69582 MX 10 spool.mu.edu. 
dawley.mil.wi.us. 69582 HINFO 386 Clone DOS 
dawley.mil.wi.us. 69582 MX 10 spool.mu.edu. 
5) The US Domain zone file must have the following records, 


showing the name, address, email, and phone number of the 
technical contact for the delegated subdomain and the name of 
the delegated name space and the names of the name servers. 


CE EP EEE EN PEER PARE Ee EE AENA EE EE EEE RAEE EE Ee EE POE Ee EE oe ee 
, 

;Contact: Joseph Klein (tjk8spool.mu.edu) 

> Marquette University 

A (414) 288-6734 

; 

;Delegate mil.wi.us zone 


mil.wi.us. 604800 NS SPOOL.MU.EDU. 
604800 NS SOPHIE.MSCS.MU.EDU. 


; A glue record is not needed this time. Glue records are 
; needed when the name of the server is a subdomain of the 
; delegated domain. 


E PEER EEE TRAER STAR ENERO RACER RATOS AE ERRE TOA CENAR TAE EA 


6) Check to see that delegated subdomain name servers are up and 
running, and make sure the delegated hosts are installed in 
their zone file. Now delete any hosts from the US Domain zone 
file that belongs in the newly delegated subdomain. 


7) Inform the technical contact of the newly delegated subdomain 
that wildcard records are allowed in the zone file under the 
organizational subdomain but no wildcard records are allowed 
under the "city" or "state" domain. 


8) Make sure each administrator has a copy of this RFC and 
follows the guidelines set forth. 


343.3 Subdomain Contacts 
The number of hosts registered under each subdomain is unknown. See 


Section 3.1 for information on the delegated domains and the 
contacts. 
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4. DATABASE INFORMATION 
4.1. Name Servers 


Name servers are the repositories of information that make up the 
domain database. The database is divided up into sections called 
zones, which are distributed among the name servers. While name 
servers can have several optional functions and sources of data, the 
essential task of a name server is to answer queries using data in 
its zones. The response to a query can always be generated using 
only local data, and either contains the answer to the question or a 
referral to other name servers "closer" to the desired information. 


A given zone will be available from several name servers to insure 
its availability in spite of host or communication link failure. 
Every zone is required to be available on at least two servers, and 
many zones have more redundancy than that. 


The US Domain is currently supported by seven name servers: 


venera.isi.edu 
ns.isi.edu 
rs.internic.net 
ns.csl.sri.com 
ns.uu.net 
adm.brl.mil 
excalibur.usc.edu 


4.2 Zone Files 


A "zone" is a registry of domains kept by a particular organization. 
A zone registry is "authoritative", that is, the master copy of the 
registry is kept by the zone organization, and this copy is, by 
definition, always up-to-date. Copies of this registry may be 
distributed to other places and kept in caches, but these caches are 
not authoritative, and may be out-of-date. 


Every zone has at least one node, and hence domain name, for which it 
is authoritative, and all of the nodes in a particular zone are 
connected. Given the tree structure, every zone has a highest node 
which is closer to the root than any other node in the zone. The 
name of this node is often used to identify the zone. The data that 
describes a zone has four major parts: 


1) Authoritative data for all nodes within the zone. 


2) Data that defines the top node of the zone 
(can be thought of as part of the authoritative data). 
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3) Data that describes delegated subzones, i.e., cuts 
around the bottom of the zone, 


4) Data that allows access to name servers for subzones 
(sometimes called "glue" data). 


The zone administrator has to maintain the zones at all the name 
servers which are authoritative for the zone. When the changes are 
made, they must be distributed to all of the name servers. 


Copies of the zone files are not available unless you are on the 
Internet. To look at the zone files use the "dig" program of the DNS 
domain name system. 


dig @nshost host-your-checking  axfr 
4.3 Resource Records 


Records in the zone data files are called resource records (RRs). 
The standard Resource records (RR) are specified in STD 13, RFC 1034 
and STD 13, RFC 1035 (3,4). An RR has a standard format as shown. 


<name> [<ttl>] [<class>] «type» «data» 


The first field is always the name of the domain record. The second 
field is an optional time to live field. This specifies how long 
this data will be stored in the data base. The third field is the 
address class; the class field specifies the protocol group most 
often this is the Internet class "IN". The fourth field states the 
type of the resource record. The fields after that are dependent on 
the Type of RR. The fifth field is the data field which is defined 
differently for each type and class of data. Here is a list of the 
current commonly used types: 


SOA Start of Authority 
NS Name Server 
A Internet Address 


CNAME Canonical Name (nickname pointer) 
HINFO Host Information 


WKS Well Known Services 
MX Mail Exchanger 
PTR Pointer 
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What do the fields mean? 


foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU. 
(1) (2) (3) (4) (5) 

1) domain name 

2) time to live information 

3) mail exchanger record 

4) preference value to determine (if more than one 


forwarder) which mailer to use first, lower number 
higher preference 
5) the Internet forwarding host. 


4.3.1 "A" Records 


Internet (IP) Address. The data for an "A" record is an Internet 
address in a dotted decimal form. A sample "A" record might look 
like: 
venera.isi.edu. A 128.9.0.32 
(name) (A) (address) 


The name field is the machine name, and the address is the network 
address. There should be only one "A" record for each address of a 
host. 


4.3.2 CNAME Records 


Canonical Name resource record, CNAME, specifies an alias fora 
canonical name. This is essentially a pointer to the official name 
for the requested name. All other RRs appear under this official 
name. A machine named FERNWOOD.MPK.CA.US may want to have the 
nickname ANTERIOR.MPK.CA.US. In that case, the following RR would be 
used: 


anterior.mpk.ca.us. CNAME fernwood.mpk.ca.us. 
(alias nickname) (canonical name) 


Nicknames (the name associated with the RR is the nickname) may be 
added for awhile when a host changes its name, usually because it 
moves to another state. It helps to have this CNAME pointer so if 
any mail comes to the old address it will get forwarded to the new 
one. There cannot be any other RRs associated with a nickname of the 
same class. 
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4.3.3 MX Records 


Mail Exchanger records, MX, are used to specify a machine that knows 
how to deliver mail to a machine that is not directly connected to 
the Internet. For example, venera.isi.edu is the mail gateway that 
knows how to deliver mail to foo.la.ca.us, but other machines on the 
network cannot deliver mail directly to foo.la.ca.us. These two 
machines may have a private connection or use a different transport 
medium (such as uucp). The preference value (10) is the order that a 
mailer should follow when there is more than one way to deliver mail 
to a single machine. The lower the number the higher the preference. 


foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU. 
foo.LA.CA.US. 604800 MX 20 relayl.uu.net. 


4.3.4 HINFO Records 


Host information resource records, HINFO is for host specific data. 
This lists the hardware and operating system that are running at the 
listed host. It should be noted that a space separates the hardware 
information and the operating system information. If you want to 
include a space in the machine name you must quote the name. Host 
information is not specific to any class, so ANY may be used for the 


address class. There should be one HINFO record for each host. 
acb.la.ca.us. HINFO VAX-11/780 UNIX 
(Hardware) (Operating System) 


The official HINFO types can be found in the latest Assigned Numbers 

RFC, the most recent edition being STD 2, RFC 1340 [9]. The hardware 
type is called the Machine Name, and the software type is called the 

System Name. 


The information users supply about this is often inconsistent or 
incomplete. Please follow the terms in the current "Assigned 
Numbers". 


4.3.5 PTR Records 

A Domain Name Pointer record, PTR, allows special names to point to 
some other location in the domain data base. These are typically 
used in setting up reverse pointers for the special IN-ADDR.ARPA 


domain. PTR names should be unique to the zone. 


0.0.9.128.in-addr.arpa PTR isi-net.isi.edu. 
(special name) (real name) 
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A PTR record is to be added to the IN-ADDR.ARPA domain for every "A" 
record registered in the US Domain. These PTR records need to be 
added by the administrator of the network where the host is 
connected. The US Domain Administration does not administer the 
network and cannot make these entries in the DNS database. 


4.4 Wildcards 


The wildcard records are of the form "*.<anydomain>", where 
<anydomain> is any domain name. The wildcards potentially apply to 
descendents of <anydomain>, but not to <anydomain> itself. 


For example, suppose a large company located in California with a 
large, non-IP/TCP, network wanted to create a mail gateway. If the 
company was called DWP.LA.CA.US, and the IP/TCP capable gateway 
machine (Internet forwarder) was called ELROY.JPL.NASA.GOV, the 
following RRs might be entered into the .US zone. 


dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV 
*.dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV 


The wildcard record *.DWP.LA.CA.US would cause an MX query for any 
domain name ending in DWP.LA.CA.US to return an MX RR pointing at 
ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host 
dwp can be found. 


In the US Domain, wildcard records are allowed in our zone files 
under the organizational subdomain (and where noted otherwise) but no 
wildcard records are allowed under the "City" or "State" domain. 


The authors strongly believe that it is in everyone's 
interest and good for the Internet to have each host 
explicitly registered (that is, we believe that wildcards 
should not be used), we also realize that not everyone 
agrees with this belief. Thus, we will allow wildcard 
records in the US Domain under groups or organizations. 
For example, *.DWP.LA.CA.US. 


The reason we feel single entries are the best is by the mere 
fact that if anyone wanted to find one of the hosts in the 
domain name system it would be there, and problems can be 
detected more easily. When using wildcards records all the 
hosts under a subdomain are hidden. 
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6. Security Considerations 


Security issues are not discussed in this memo. 
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APPENDIX-I: US DOMAIN NAMES BNF 


«us-domain-name» ::— «us-name»«dot»«us» 


«us-name» : := <state-name><dot><state-code> | 
«fed-name»«dot»«fed» 
«dni-name»«dot»«dni» 


<state-code> : := «the two-letter code of a state from the 
zip code directory> 


<state-name> : := <local-name><dot><locality> | 
<state-agency-name><dot><state> | 
<regional-agency-name><dot><agency> 


<fed-name> : := «the dotted hierarchical name of a US 
federal government agency> 


<dni-name> ::— «the dotted hierarchical name of a 
distributed national institution» 


«locality» ::= «the full name of a city from the 
zip code directory» | 
«a short code name for a city» | 
«the full name of a county, township, 
or parish» | 
«other well known and commonly used 
locality name» 


<local-name> ::= <entity-name> | 
<city-name><dot><city> | 
<county-name><dot><county> | 
<local-agency-name><dot><local-agency> 


<state-agency-name> ::= <the dotted hierarchical name of a state 
government agency> 


<regional-agency-name> ::= <the dotted hierarchical name of a 
special agency or district not an 
element of the state government and 
typically larger than a single city or 
county, for example, the Southern 
California Air Quality Management District> 
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<entity-name> 


<city-name> 


<county-name> 


<local-agency-name> 


The US Domain June 1993 


<the dotted hierarchical name of an 
entity within a city, for example: a 
company, business, private school, club, 
organization, or individual> 


<the dotted hierarchical name of a city 
government agency> 


<the dotted hierarchical name of a county, 
township, or parish government agency> 


<the dotted hierarchical name of a special 
agency or district not an element of a 
city or county government and typically 
equal or smaller than a single city or 
county, for example, the Bunker Hill 
Improvement District> 


<city> ¿15 "ort. Sorry" 

<county> ::= "CO" | "COUNTY" | "TOWNSHIP" | "PARISH" 

«dot» ::= "," 

«fed» ::- "FED" 

«dni» ::= "DNI" 

«state» ::- "STATE" | "COMMONWEALTH" 

«ageney* ::= "AGENCY" | "DISTRICT" | “K12" | "cc" | "LIB" 
"GEN" |. “ERC” 

<local-agency> ::= "AGENCY" "DISTRICT" 


<us> ::= "US" 


Notes: 


Within States: 


"K12" may be used for public school districts. A special name 
"PVT" can be used in the place of a school district name for 


private schools. 


"CC" may be used only for public community colleges. 
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"LIB" may be only used by libraries. 


"TEC" is used only for technical and vocational schools and colleges. 
"GEN" is for general independent entities, that is, organizations 
that don’t really fit anywhere else (such as statewide associations, 
clubs, and "domain parks"). 

"STATE" may be used only for state government entities. 

Below US, parallel to States: 

"FED" is for agencies of the federal government. 

"DNI" is for distributed national institutes; organizations that 


span state, regional, and other organizational boundaries; that 
are national in scope, and have distributed facilities. 


Examples: 
Geo-Petrellis.Culver-City.CA.US <== resturant 
Joe-Josts.Long-Beach.CA.US <== bar 
IBM.Armonk.NY.US <== business 
Camp-Curry.Yosemite.CA.US <== business 
Yosemite.NPS.Interior.FED.US <== federal agency 
Senate.FED.US <== US Senate 
DOD.FED.US <== US Defense Dept. 
DOT.FED.US <== US Transportation Dept. 
MNPL.FRB.FED.US <== the Minneapolis branch of 
the Federal Reserve Bank 
MetaCenter.DNI.US <== distributed Nat'l Inst 
Senate.STATE.MN.US <== state Senate 
House.STATE.MN.US <== state House of Reps 
Assembly.STATE.CA.US <== state Assembly 
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MDH.STATE.MN.US 

DOT.STATE.MN.US 

CALTRANS .STATE.CA.US 

DMV.STATE.CA.US 
Culver-City.DMV.STATE.CA.US 
Police.CI.Culver-City.CA.US 
Fire-Dept.CI.Los-Angeles.CA.US 
Fire-Dept.CO.Los-Angeles.CA.US 
Main.Library.CI.Los-Angeles.CA.US 
MDR.Library.CO.Los-Angeles.CA.US 
Huntington.LIB.CA.US 
SMCC.Santa-Monica.CC.CA.US 
Trade-Tech.Los-Angeles.CC.CA.US 
Valley.Los-Angeles.CC.CA.US 
Hamilton.High.LA-Unified.K12.CA.US 
Sherman-Oaks.Elem.LA-Unified.K12.CA.US 
John-Muir.Middle.Santa-Monica.K12.CA.US 
St-Monicas.High.Santa-Monica.CA.US 
Crossroads-School.Santa-Monica.CA.US 
Mary-Ellens-Montessori-School.LA.CA.US 
Progress-Learning-Center.PVT.K12.CA.US 


Brick-and-Basket-Institute.TEC.CA.US 


Bunker-Hill.DISTRICT.Los-Angeles.CA.US 


SCAOMD.DISTRICT.CA.US 
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local 
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Health Dept. 

Transportation Dept 
Transportation Dept 
Motor Vehicles Dept 


office of DMV 


city department 


city department 


county 


department 


city department 


county 
privat 
public 
public 
public 
public 
public 
public 
privat 
privat 
privat 
privat 
techni 
local 


region 


department 
e library 
community college 
community college 
community college 
school 
school 
school 
e school 
e school 
e school 
e school 
cal college 
district 


al district 
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Berkeley.UC.STATE.CA.US <== "CAL" 
Los-Angeles.UC.STATE.CA.US <== UCLA 
Irvine.UC.STATE.CA.US <== UC Irvine 
Northridge.CSU.STATE.CA.US <== CSUN 
Los-Angeles.CSU.STATE.CA.US <== Cal State LA 
Leland-Stanford-Jr-University.Stanford.CA.US <== private school 
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APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY 


To register a host in the US domain, the US Domain Template must be 
sent to the US Domain Registrar (US-Domain@ISI.EDU). The first few 
pages explain each question on the attached template. FILL OUT THE 
TWO PAGE TEMPLATE AT THE END. Questions may be sent by electronic 
mail to the above address, or by phone to Ann Cooper, USC/Information 
Sciences Institute, (310) 822-1511. 


(1) Please specify whether this is a new application, modification to 
an existing registration, or deletion. 


(2) The name of the domain. This is the name that will be used in 
tables and lists associating the domain with the domain server 
addresses. See RFC 1480 - The US Domain for more details. 


<host>.<city/locality>.<state>.US. = city/locality based names 
<school>.<district>.K12.<state>.US. = kindergarten thru 12th grade 
<school>.PVT.K12.<state>.US. = private K thru 12th grade 
<school>.<locality>.<state>.US. = PVT sch opt: locality names 
<school>.CC.<state>.US. = community colleges 
<school>.TEC.<state>.US. = technical or vocational schools 
<lib-name>.LIB.<state>.US. = libraries 
<org-name>.STATE.<state>.US. = state government agencies 
<org-name>.FED.US. = federal government agencies 
<org-name>.DNI.US. = distributed national institutes 
<org>.GEN.<state>.US. = statewide assoc,clubs,domain parks 


For example:  networthy.santa-clara.ca.us. 


(3) The name of the entity represented, that is, the organization 
being named. For example: The Networthy Corporation. Not the 
name of the organization submitting the request. 


(4) Please describe the domain briefly. 


For example: The Networthy Corporation is a consulting 
organization of people working with UNIX and the C language 


in an electronic networking environment. It sponsors two 
technical conferences annually and distributes a bimonthly 
newsletter. 


(5) The date you expect the domain to be fully operational. 


Cooper & Postel [Page 42] 


RFC 1480 The US Domain June 1993 


For every registration, we need both the Administrative and the 
Technical contacts of a domain (questions 6 & 7) and we MUST have a 


network mailbox for each. If you have a NIC handle (a unique NIC 
database identifier) please enter it. (If you don’t know what a NIC 
handle is leave it blank). Also the title, mailing address, phone 


number, organization, and network mailbox. 


(6) The name of the administrative head of the "organization". The 
administrator is the contact point for administrative and policy 
questions about the domain. The Domain administrator should work 
closely with the personnel he has designated as the "technical 
contact" for his domain. In this example the Domain Administrator 
would be the Administrator of the Networthy Corporation, not the 
Administrator of the organization running the name server 
(unless it is the same person). 


(7) The name of the technical and zone contact. The technical and 
zone contact handles the technical aspects of maintaining the 
domain’s name server and resolver software, and database files. 
He keeps the name server running. More than likely, this person 
would be the technical contact running the primary name server. 


大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 大 


PLEASE READ: There are several types of registrations. 


(a) Delegation (i.e., a portion of the US Domain name space is 
given to an organization running name servers to support that 
branch; For example, K12.TX.US, for all K12 schools in Texas). 
For (a) answer questions 8 and 9. 


(b) Direct Registration of an IP Host. 
For (b) answer question 10. 


(c) Direct Registration of a non-IP Host. 
For (c) answer question 11 and 12. 


ACC Ck Ck Ck CK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK kx AG Kk ko ko kocko 

QUESTIONS FOR DELEGATIONS 

(8) PRIMARY SERVER Information. It is required to supply both the 
Contact information as well as hardware/software information of 


the primary name server. 


(9) * SECONDARY SERVER Information. It is required to supply the 
hardware and software information of all secondary name servers. 
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Domains must provide at least two independent servers that provide the 
domain service for translating names to addresses for hosts in this 
domain. If you are applying for a domain and a network number 
assignment simultaneously and a host on your proposed network will be 
used as a server for the domain, you must wait until you receive your 
network number assignment and have given the server(s) a net- address 
before sending in the domain application. Establishing the servers in 
physically separate locations and on different PSNs and/or networks is 
strongly recommended. 


NOTE: For those applicants not able to run name servers, or for non-IP 
hosts the Name Server information is not applicable. (See 410 and 411). 


QUESTION FOR DIRECT IP HOSTS (If you answered 8 & 9 do not answer 
10, 11, or 12). 


(10) What Domain Name System (DNS) Resource Records (RR) and values are 
to be entered for your IP host (must have an "A" record). 


十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
Example: RRs for an INTERNET hosts. 


(a) DOMAIN NAME (required)...: Networthy.Santa-Clara.CA.US. 
(b) IP ADDRESS (required)....: A 128.9.3.123 (required) 

(c) HARDWARE (opt)...........: SUN-3/110 

(d) OPERATING SYS (opt)......: UNIX 

(e) WKS (opt)........: 128.9.3.123. UDP (echo tftp) TCP (ftp) 
(E). ¿ME (OPE) Lepre RR ee 0 (RELAY o TSL iEDU. 


It is your responsibility to see that an IN-ADDR pointer record is 
entered in the DNS database. (For Internet hosts only). Contact the 
administrator of the IP network your host is on to have this done. 
The US Domain administration does not administer the network and 
cannot make these entries in the DNS database. 


QUESTIONS FOR NON-IP HOSTS (such as UUCP). 


Many applicants have hosts in the UUCP world. Some are one hop away, 
some two and three hops away from their "Internet Forwarder", this is 
ok. What is important is getting an Internet host to be your 
forwarder. If you do not already have an Internet forwarder, there 
are several businesses that provide this service for a fee, (see 

RFC 1359 - Connecting to the Internet What Connecting Institutions 
Should Anticipate, ACM SIGUCCS, August 1992). Sometimes local colleges 
in your area are already on the Internet and may be willing to act 

as an Internet Forwarder. You would need to work this out with the 
systems administrator. We cannot make these arrangements for you. 
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(11) Internet Forwarding Host Information 


(lla) What is the name of your Internet forwarding host? 
For example: The host Yacht-Club.MDR.CA.US uses 
UUCP to connect to RELAY.ISI.EDU which is an Internet 
host. (i.e., RELAY.ISI.EDU is the forwarding host). 


(11b) What is the name of your contact person at forwarding host? 
The Administrator of RELAY.ISI.EDU must agree to be the 
forwarding host for Yacht-Club.MDR.CA.US, and the 
forwarding host must know a delivery method and route to 
Networthy. No double MXing. 


(11c) What is the mailbox of your contact? 


What is the mailbox of the administrator of the forwarding 
host. 


Example: Contact Name......: John Smith 
Contact Email.....:  jsQRELAY.ISI.EDU 


(12) What Domain Name System (DNS) Resource Records (RR) and values 
are to be entered for your NON-IP host. 


十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
Example: RRs for a NON-IP host (uucp). 


(a) DOMAIN NAME (required).....: Yacht-Club.MDR.CA.US. 
(b) HARDWARE (opt).............1 SUN-3/110 

(c) OPERATING SYS (opt)........: UNIX 

(d) MX (required)..............: 10 RELAY.ISI.EDU. 

十 十 十 


十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 


PLEASE ALLOW AT LEAST 8 WORKING DAYS FOR PROCESSING THIS APPLICATION 
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US DOMAIN TEMPLATE [6/93] 


PLEASE SUBMIT THE FOLLOWING TWO PAGE TEMPLATE TO (Us-Domain@isi.edu). 
Sections or fields of this form marked with an asterisk (*) may be 
copied as many times as necessary. (For example: If you had two phone 
numbers for the Administrative Contact, you would use the same number 
"6h" twice. PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY. 


T REGISTRATION TYPE 
(N)ew (M)odify (D)elete..: 


2.* FULLY-QUALIFIED DOMAIN NAME: 


3. ORGANIZATION INFORMATION 
3a. Organization Name.....: 
3b. Address Line 1........: 
3b. Address Line 2........: 


4. DESCRIPTION OF ORG/DOMAIN: 
5i. Date Operational......: 
6. ADMINISTRATIVE CONTACT OF ORG/DOMAIN 


6a. NIChandle (if known)..: 
6b. Whole Name............: 
6c. Organization Name.....: 
6d. Address Line 1........: 
6d. Address Line 2........: 


69%, Zyp/GCOode. a a 
6h.* Vorce Phone... jewel 
* 


7. TECHNICAL AND ZONE CONTACT 
Ja. NIChandle (if known)..: 
7b. Whole Name............: 
7c. Organization Name.....: 
Td: Address Line I. ndo 
Jd. Address Line 2...52.:...4 
Lea echo cR 
dX HSAs ca is Lu 
TOs JAXp/GCOdSG..-. eS 
7h.* Voice Phone...........: 
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FILL OUT QUESTIONS 8 AND 9 FOR DELEGATIONS ONLY (i.e., those 
organizations running name servers for a branch of the US Domain 
name space, for example: k12.<state>.us). 


8. PRIMARY SERVER: CONTACT INFO, HOSTNAME, NETADDRESS 
8a. NIChandle (if known)..: 
8b. Whole Name............: 
8c. Organization Name.....: 
8d. Address Line 1........: 
8d. Address Line 2........: 


8g.- ZIP Coden s S Panera ceased 
8h.* Voice Phone...........: 


8m.* OPERATING SYS.........: 
9. * SECONDARY SERVER: HOSTNAME, NETADDRESS 
9a.*-Hostname.;.... vel 
Op *.BP-AddrSsSsl.wes xev 
9c.* HARDWARE. .............! 
9d.* OPERATING SYS.........: 


FILL OUT QUESTION 10 FOR DIRECT REGISTRATIONS IP HOSTS 


10. RESOURCE RECORDS (RRs) FOR IP INTERNET HOSTS 
10a. DOMAIN NAME...........: 
10b.* IP ADDRESS (required).: 
l0G. "HARDWARE... XS 
10d. OPERATING SYS.........: 
POG MES dud eM aut 
TOFA MX. opiate ce wie See Le wk 


FILL OUT QUESTIONS 11 AND 12 FOR NON-IP HOSTS (such as UUCP) 


Lg FORWARDING HOST INFORMATION 
lla. Forwarding Host......: 
11b. Contact Name.........: 
llc. Contact Email........: 


12. RESOURCE RECORDS (RRs) FOR NON-IP HOSTS (UUCP) 
12a. DOMAIN NAME...........: 
12D; HARDWARE..............t1 
12c. OPERATING SYS.........: 
12d.* MX (required) .........: 
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